To me, i think this should be something like

.gitignore

/vendor
/composer.lock
/.phpunit.result.cache

.gitattributes

/.git* export-ignore
/.symfony.bundle.yaml export-ignore
/assets/src export-ignore
/assets/test export-ignore
/phpunit.xml.dist export-ignore
/tests export-ignore

(without the assets line when/if not needed)

Probably also add when necessary

• vitesst.config (ex: turbo)
• docker-compose (ex: turbo)
• phpstan (ex: turbo)

Be careful Turbo has some custom CI ;)

So is there still something to agree on here? Can i help you on something @Kocal ?

I didn't take a look since, maybe tonight!

I don't like adding generated files (phpunit/phpcs/.. cache) ... but if we use CI actions that commit (auto-CS ?) this makes sense.

But i also realised all of those are already ignored in the root .gitignore

.doctor-rst.cache
.php-cs-fixer.cache
node_modules
yarn-error.log
/composer.lock
/vendor

(we may add phpunit.result.cache here)

So, after your explanations, the package folders could contain:

.gitignore

# not sure if here .. maybe in the global gitignore
/.php-cs-fixer.cache 
/.phpunit.result.cache 

# is the root one not enough ?
/assets/node_modules/

/vendor/
/composer.lock
/phpunit.xml

(with aditional files depending on the package content)

.gitattributes

/.gitattributes export-ignore
/.gitignore export-ignore
/.symfony.bundle.yaml export-ignore
/assets/src export-ignore
/assets/test export-ignore
/phpunit.xml.dist export-ignore
/tests export-ignore

(with aditional files depending on the package content)

# And soon
/doc/ export-ignore # as no one want to read raw RST file in their vendor folder
/phpstan.dist.neon export-ignore # if not in the root repo

Side question @Kocal :
Would it be something complicated / with consequences to put the node_module in the root directory of each package ? Or maybe "not advised" ?

So we may only need to update the root .gitignore one for now :)

Would it be something complicated / with consequences to put the node_module in the root directory of each package ? Or maybe "not advised" ?

Not complicated, but really not wanted. With this kind of project structure you want to use Yarn workspaces (added in #9 :D)

Rebased / clean in ##2243 .. LGTM !